I think that the logic here and in fetchDataSource where we need to check type is a bit complicated - it might be hard to find an error in the code or reconsider some of the columns or data structure when all three pages' configs are so connected. do you think it's possible and makes sense to split it all into three configs for columns and dataSource?

Yes, that makes complete sense. I would like to refactor this in upcoming PRs to avoid too much change here 🙏

Hmm, sure. Does it add any improvements?

yeah, there's a small difference

using this plugin: https://marketplace.visualstudio.com/items?itemName=ambar.bundle-size

not 100% sure if it's accurate post-build, but if it is then we should consider reducing where we can

ahh, nice!

this is a component with a single export, please move to components folder and name Details.jsx

This is currently used by agents, components, and services, so I've kept it in the common-utils. Any reason to move it to components folder instead?

sure, so...

the components folder is for reusable components i.e. this Details component, used by multiple others

the pages folder should be reserved for specific pages that pull in reusable components to create the expected page

the common-utils or utils folders should be for helper functions, i.e. string parsers, converters, object manipulation .etc, perhaps constants, though I tend to put it outside of utils folder to seperate concerns

I understand your point, but my approach differs slightly:

• page simply imports the core components. I believe if we start adding the core components here, it will become too large to maintain, especially since they tend to grow in size.
• components is for core components such as Agents, Services, etc.
• common-util is intended for common components that can be used by other core components. For example components that can be used in Agents, Services, etc
• utils is reserved for constants, but we could potentially move it to common-util.

I think eventually, the truly reusable components will be moved to feature libraries in NX, such as the login component, utility functions, etc.

remove all the awaits from these functions if the response isn't processed
we can't batch them with Promise.all or Multicall otherwise

I'm a bit confused here. Could you provide an example?

error on my behalf, ran some tests, functions as expected, no need to remove them.
in fact, return await is now more performant?
https://eslint.org/docs/latest/rules/no-return-await